【第2403期】打造Snowpack到20,000 Stars的5个经验之谈

前言

中秋假期，睡醒阅读。每个开源项目的作者都需要勇气。今日前端早读课文章由@飘飘翻译分享。

正文从这开始~~

My name is Fred, and I created Snowpack. If you're not familiar, Snowpack is a web build tool that fundamentally unlocked the "unbundled web development" movement that Snowpack, Vite, SvelteKit and other modern dev tools leverage today.

我叫Fred，我创建了Snowpack。如果你还不熟悉，可以告诉你，Snowpack是一个web构建工具，它从根本上开启了Snowpack、Vite、SvelteKit和其他现代开发工具所利用的“非捆绑web开发”运动。

In this post, I want to share 5 things that I learned growing Snowpack from the initial commit to almost 20,000 GitHub stars and over 1,000,000+ downloads.

在这篇文章中，我想和大家分享我从 Snowpack 中学到的5件事情，这些事情从最初提交到将近20000个 GitHub stars 和超过1000000次的下载中学到的。

This post is meant for anyone interested in Open Source software. The highlighted lessons are directed at anyone who is interested in starting their own open source project or contributing to an existing project.

这篇文章是写给所有对开源软件感兴趣的人的。重点介绍是针对那些有兴趣开始自己的开源项目或为现有项目做贡献的人。

This will be a 2-part series: In this first post I focus on lessons learned creating Snowpack from scratch and finding our first set of users. In part two, I will focus what it's like to maintain a popular open source project, at scale.

这将是一个两部分组成的系列。在第一篇文章中，我将重点介绍从零开始创建Snowpack和寻找第一批用户的经验教训。在第二部分中，我将重点介绍如何大规模维护一个受欢迎的开源项目。

Background

项目背景

A couple of years ago, I started an experimental JavaScript project. Codename: Pika. It had a cute, blue mouse mascot and a fun vibe that a bunch of smaller experimental projects could live under. Its unifying mission could be best summarized as, "ESM is this cool new technology, lets do more stuff with it."

几年前，我开始了一个实验性的JavaScript项目。代号：Pika。它有一个可爱的、蓝色的老鼠吉祥物和一堆小实验项目可以生活的有趣的氛围。它的统一使命可以最好地概括为："ESM是一项很酷的新技术，让我们用它做更多的事情。"

That first year of Pika may have been the most productive year of my life. I created @pika/pack (a publishing tool for npm package authors), Pika CI (a Github action that let you npm install or even import() any GitHub PR), a failed in-browser code editor, and a next-gen JavaScript CDN that went on become Skypack.

Pika的第一年可能是我一生中收获最多的一年。我创建了@pika/pack（一个为npm包作者的发布工具），Pika CI（一个Github action，允许npm安装甚至导入任何GitHub PR），一个失败的浏览器内代码编辑器，以及一个继续运行的下一代的JavaScript CDN，后来成为Skypack。

The biggest standout of the bunch was @pika/web, which let you install any npm package to run directly in the browser without a bundler (ex: react -> /react.js). You probably know this project better under its newer name: Snowpack.

其中最突出的是@pika/web，它允许你安装任何npm包，直接在浏览器中运行，而无需bundler（例如：react -> /react.js）。你可能更了解这个项目的新名字：Snowpack。

Below are five lessons that I learned while growing Snowpack from its first commit to the official v1.0 release, and how we found our first set of users.

下面是我从Snowpack从第一次提交到正式发布V1.0版本的过程中学到的五条经验，以及我们如何找到第一批用户的。

Lesson 1: Start with a personal frustration

第一课：从个人挫折感开始

Snowpack began as a tool to convert any npm package to a single JavaScript file that you could run in the browser. Sounds boring, right? Wrong!

Snowpack最初是一个将任何npm包转换为单一的JavaScript文件的工具，以便在浏览器中运行。听起来很无聊，对吗？错了!

This small, straightforward tool would unlock an entirely new mode of web development that is now referred to as "Unbundled Web Development". Unbundled development introduced features like instant reloads and near-instant startup time during development, using a process that wouldn't slow down as your project grows to 1,000 or even 10,000+ files. Compare this to more traditional bundled dev environments, where multi-second startup and reload times are still the norm today.

这个小巧简单的工具将开启一种全新的web开发模式，现在被称为 "Unbundled式网络开发"。Unbundled式开发引入了一些特性，比如在开发过程中即时重载和近乎即时的启动时间，使用的流程不会随着项目增长到1,000甚至10,000多个文件而变慢。相比之下，几秒的启动和重新加载时间今天仍然是常态。

The original idea for Snowpack came out of a simple, personal frustration that I had been having at work. I was working on the Polymer team at Google, where I had helped create some alterative build tools for the (now dead) HTML Imports spec. The tool itself was lovely, but it didn't work well with npm and very few people ever used it.

Snowpack的最初想法来自于我在工作中遇到的一个简单的个人的挫折。我当时在谷歌的Polymer团队工作，在那里我帮助创建了一些替代性的 HTML Imports 规范构建工具。这个工具本身很好，但它与npm不兼容，很少有人使用它。

I eventually left the Polymer team, but that problem still stuck in my head: Why had bundlers like webpack become the only way to use npm packages in the browser? Something has to solve the problem of getting npm packages to run in the browser, but did it have to involve bundling your entire website? Snowpack was my attempt to find out whether another path was possible.

我最终离开了Polymer团队，但是那个问题仍然困扰着我：为什么像webpack这样的打包器成了在浏览器中使用npm包的唯一方式？必须要有办法解决让npm包在浏览器中运行的问题，但是否一定要把你的整个网站捆绑起来？Snowpack是我试图找出另一条路是否可行的尝试。

Lesson for open source maintainers: Build for yourself, first. If you're frustrated by something, chances are other developers are too. Question everything.

给开源维护者的教训：首先为自己构建。如果你对某件事情感到沮丧，那么其他开发者也有可能会这样。质疑一切。

Lesson 2: move fast, stay small

第二课：快速行动，保持低调

When you're working on a new project, you rarely know what code will be important long-term and what code is about to be deleted. I've thrown away enough code in my career to have learned that there's sometimes value in fast, messy coding. When you're starting a new project, it's okay to be a bit messy.

当你在一个新项目上工作时，你很少知道哪些代码将是重要的，哪些代码即将被删除。在我的职业生涯中，我已经丢弃了足够多的代码，从而了解到快速而混乱的编码有时是有价值的。当你开始一个新的项目时，有点乱是可以的。

Internally, almost all of Snowpack's complexity was handled by Rollup. Snowpack was really just a wrapper around Rollup that would bundle only your npm packages instead of your entire website. Realizing that Snowpack could leverage Rollup internally saved me weeks (or maybe even months) of development time.

在内部，几乎所有Snowpack的复杂性都由Rollup处理。Snowpack实际上只是一个围绕Rollup的包装器，它只打包你的npm包，而不是你的整个网站。意识到Snowpack可以在内部利用Rollup，为我节省了数周（甚至数个月）的开发时间。

To be honest, Snowpack was just a single index.js file for the majority of its life.

说实话，Snowpack的大部分时间只是一个index.js文件。

To keep the project on track, I focused on a single feature: "give me a package name, and I'll convert it to ESM." This would be too low-level for most web developers. In fairness, Snowpack really didn't take off with a large audience until we added a built-in dev server and build command in v2.0. But even without the dev server, Snowpack's small v1.0 focus was enough for a certain kind of low-tooling/no-tooling web developer.

为了保持项目的进度，我把注意力集中在一个单一的功能上。"给我一个包名，我就把它转换为ESM"。这对大多数网络开发者来说太低级了。公平地说，直到我们在2.0版中添加了内置的开发服务器和构建命令，Snowpack才真正获得了大量用户。但即使没有开发服务器，Snowpack对1.0版本的关注也足以满足某种低工具/无工具的web开发人员。

My overeall recommendation is to test your idea and get together a working demo as quickly as possible. In practice, this means four things:

我的建议是尽快测试你的想法，并制作一个可运行的demo。实际上，这意味着四件事：

Use existing tools! Fork a similar open source project or use an existing tool internally if it can save you time.

使用现有的工具! 如果可以节省你的时间，那么就Fork一个类似的开源项目，或者在内部使用现有的工具。

Write messy code! At the earliest stage, you probably don't know exactly know what you're building. Premature refactoring can sometimes be worse than never refactoring at all, so keep your code flexible for as long as possible.

编写混乱的代码! 在最初的阶段，你可能并不确切知道你在构建什么。过早的重构有时会比根本没有重构更糟糕，所以尽可能的保持你的代码的灵活性。

Keep scope small! Don't build half-baked, half-working features. Instead, focus on doing one thing very well.

保持小范围! 不要构建半成品功能。相反，要专注于把一件事做得非常好。

Skip tests! Confirm that you're building something useful before spending your free time writing tests for it. Nothing is worse than writing tests for something that you end up never using.

跳过测试! 在空闲时间编写测试之前，确认你正在构建一些有用的东西。没有什么比为一些你最终不会使用的东西写测试更糟糕的了。

I know that some of this could be considered a hot/controversial take. "No testing??? Blasphemy!" All I can say is that this strategy has worked well for me over several popular projects and countless unpopular projects that went nowhere.

我知道这其中有一些可能被认为是热门/有争议的观点。"没有测试？亵渎！" 我所能说的是，这个策略在我的几个受欢迎的项目和无数不受欢迎的项目中都很有效。

The obvious downside to this "move fast" advise is that it is not sustainable long-term. Moving fast means taking on tech debt, which you will absolutely need to repay at some point if your project becomes successful. As soon as you have some users who like what you're doing, you should begin to re-prioritize stability, refactoring and testing. More on this in the next post.

这种 "快速行动 "的建议的明显缺点是，从长期来看，它是不可持续。快速行动意味着承担技术债务，如果你的项目成功了，你绝对需要在某个时候偿还这些债务。一旦有一些用户喜欢你所做的事情，您就应该开始重新优先考虑稳定性、重构和测试。在下一篇文章中会有更多这方面的内容。

Paying down tech debt can be a slog. But, silver lining: If your project never takes off, then congratulations! You didn't waste any time testing something that no one wanted :)

偿还技术债务可能是一件苦差事。但是幸运的是。如果你的项目没有成功，那么恭喜你！你没有浪费任何时间去测试那些没有人想要的东西 :)

Lesson for open source maintainers: Write messy code, keep scope small, and skip any unnecessary work until you know that you're building something useful.

对开源维护者的教训：写乱七八糟的代码，保持较小的范围，跳过任何不必要的工作，直到你知道你正在构建有用的东西。

Lesson 3: Fix fast

第三课：快速修复

You just received your first bug report. Oh no, someone tried your project out and it broke! But what matters is that they cared enough to tell you about it.

你刚刚收到你的第一个错误报告。哦，不，有人试用了你的项目，结果它坏了！但重要的是，他们关心并告诉你这个问题。

One of the best things that you can do in a new open source project is fix bug reports right as they come in. Prioritizing fixes over everything else becomes much harder as a project grows, so enjoy the freedom to move quickly while you still can.

在一个新的开源项目中，你可以做的最好的事情之一就是在收到错误报告时立即修复。随着项目的发展，将修复优先于其他任何事情会变得更加困难，所以在你还可以的时候，请享受快速行动的自由。

Sebastian McKenzie (creator of Babel, Yarn, and now Rome) summarizes this theory well:

Sebastian McKenzie（Babel、Yarn和现在的Rome的创建者）很好地总结了这个理论：

One of the reasons Babel was successful is how quickly I was able to quickly fix bugs and release new versions. I would regularly have releases out within minutes of a bug report. This was critical during the early days when adoption was low. Being able to unblock users quickly would often make them more excited to use Babel even though they ran into a bug. -- Sebastian McKenzie, Rome

Babel成功的原因之一是我能够快速地修复bug并发布新版本。我经常在接到错误报告后几分钟内就发布了新版本。在采用率低的早期，这至关重要的。如果能够快速解锁用户，他们就会更乐意使用Babel，即使他们遇到了错误。-- Sebastian McKenzie，罗马

Lesson for open source maintainers: Your first users are essential. Prioritize fixing their issues over everything else.

对开源维护者的教训:你的第一批用户是至关重要的。优先解决他们的问题。

Lesson 4: Practice good storytelling

第四课：练习讲好故事

Something about marketing always seems to make developers squeamish. Unfortunately, if you want people to use your project you eventually need to tell them about it. Even organic, viral word-of-mouth sensations tend to have a cheerleader acting behind-the-scenes.

关于市场营销的东西似乎总是让开发者感到胆怯。不幸的是，如果你想让人们使用你的项目，你最终需要告诉他们它。即使是有机的、病毒式的口碑传播，也往往有一个拉拉队在幕后行动。

To start, just share your project with a friend or colleague and ask them for their thoughts. It's okay if you don't hit the front page of Hacker News on day one, all you're looking for is early feedback and maybe your first users.

首先，与朋友或同事分享你的项目，并征求他们的想法。如果你没有在第一天就登上Hacker News的头版也没关系，你所寻找的只是早期的反馈，也许是你的第一批用户。

When you're ready to share your project with a larger audience, you have a few options for how to do it. One popular choice is to tell your story in small, visual pieces over time. This is how Sebastian built excitement for Rome for almost 2 years before its launch. Mark Dalgleish has also done a great job of promoting vanilla-extract on Twitter this way.

当你准备与更多的人分享你的项目时，你有几个选择来做这件事。一个流行的选择是，随着时间的推移，用小的、可视觉化的作品来讲述你的故事。这就是塞巴斯蒂安如何在《罗马》推出前的2年时间里为它制造兴奋。马克-达格利什（Mark Dalgleish）也用这种方式在推特上推广了香草提取物。

You can also get creative, and do something unique. Ben Holmes has been having a ton of fun recording announcement videos in front of a whiteboard for his new project, Slinkity.

你也可以变得有创意，做一些独特的事情。本·霍姆斯(Ben Holmes)为他的新项目Slinkity在白板前录制了大量有趣的宣传视频。

With Snowpack, I decided to tell our story in one big blog post. This took some serious time to write, but gave us the space to really explain the "why" of the project. I figured that we had to make an emotion connection to our bigger goal to change the web. Even though this was just a single post, it made a big splash when it was released and then got re-shared and referenced over the next year.

对于Snowpack，我决定用一篇大的博客文章讲述我们的故事。这需要花一些时间来编写，但这也给了我们足够的空间来真正解释这个项目的“原因”。我认为我们必须将情感与改变网络的更大目标联系起来。尽管这只是一篇文章，但它在发布时引起了很大的轰动，然后在接下来的一年里被重新分享和引用。

Lesson for open source maintainers: Promote your work. Find a style of storytelling that fits you and your project.

开源维护者的教训：推广你的工作。找一种适合你和你的项目的讲故事的方式。

Lesson 5: Ignore your haters, listen to your users

第五课：忽略你的讨厌者，倾听你的用户

If your work ever gets posted to Hacker News, expect some haters.

如果你的作品被发布到Hacker News上，恐怕会有人讨厌你。

If you're lucky, you can tell the difference between ignorant criticism and constructive criticism. Ignore the ignorant stuff (aka haters) but listen to the constructive feedback if you can. If someone shows that they took the time to at least attempt to understand your project in good faith, their feedback will usually have some value if you can spot.

如果你幸运的话，你可以分辨出无知的批评和建设性的批评。忽略那些无知的东西（也就是讨厌的人），但如果可以的话，听听建设性的反馈。如果有人愿意花时间去理解你的项目，他们的反馈通常是有价值的。

A common constructive criticism is when someone clearly tried understand your work, but still misunderstood some key part of it. It's easy to call that person dumb and move on, but remember that clear communication is your responsibility. When someone misunderstands your work, it usually means that you could improve your README or documentation or general storytelling in some way.

一种常见的建设性批评是，有人清楚地试图理解你的工作，但仍然误解了其中的一些关键部分。骂那个人是很容易的，但请记住，清晰的沟通是你的责任。当有人误解你的工作时，这通常意味着你可以在某些方面改进你的README或文档或一般的叙述方式。

Lesson for open source maintainers: Haters gonna hate, ignore them. Learn how to spot the good-faith, constructive criticism.

开源维护者的教训：讨厌的人就是讨厌，不要理会他们。学习如何识别善意的、建设性的批评。

Main Takeaway: Support your early users

主要启示：支持你的早期用户

If you're starting a new open source project, the best thing that you can do is make sure that your first 10 users are happy. All of the lessons above are really just about finding and supporting these first users in some way. If you do right by them, then you've already built something meaningful.

如果你正在启动一个新的开源项目，你能做的最好的事情就是确保你的前10个用户是满意的。以上所有的教训实际上是关于如何找到并支持第一批用户。如果你对他们做得对，那么你就已经建立了一些有意义的东西。

And if this all sounds like too much work, remember that open source software has no rules. It's supposed to be fun. Building for yourself or a smaller audience is totally fine, in which case you can go ahead and ignore most of this advice.

如果这一切听起来像太多的工作，请记住，开放源码软件是没有规则的。它应该是有趣的。为自己或更少的用户构建是完全可以的，在这种情况下，你可以忽略大部分建议。

Snowpack项目地址：https://github.com/snowpackjs/snowpack

关于本文
译者：@飘飘
作者：@Fred K. Schott
原文：https://dev.to/fredkschott/5-things-i-learned-while-building-snowpack-to-20-000-stars-b9d

为你推荐

有开源项目欢迎投稿，前端早读课等你来，可以联系情封vx:zhgb_f2er